System and Method for Providing Persistent Authentication in an Information Handling System

ABSTRACT

An information handling system includes a secure resource, an input device that receives an authentication credential from a user and generates authentication information based upon the authentication credential, an authentication engine that receives the authentication information and provides confidence information based upon the authentication information, and an authentication agent that receives the confidence information and grants the user a level access to the secure resource based upon the confidence information.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a non-provisional of U.S. Provisional ApplicationNo. 62/105,090, filed on Jan. 19, 2015, the disclosure of which ishereby expressly incorporated by reference in its entirety.

Related subject matter is contained in co-pending U.S. patentapplication Ser. No. 14/______ (DC-106692) entitled “System and Methodfor Providing an Authentication Engine in a Persistent AuthenticationFramework,” filed of even date herewith, the disclosure of which ishereby incorporated by reference.

Related subject matter is contained in co-pending U.S. patentapplication Ser. No. 14/______ (DC-106693) entitled “System and Methodfor Providing an Authentication Agent in a Persistent AuthenticationFramework,” filed of even date herewith, the disclosure of which ishereby incorporated by reference.

Related subject matter is contained in co-pending U.S. patentapplication Ser. No. 14/______ (DC-106694) entitled System and Methodfor Providing Confidence Scores in a Persistent Framework,” filed ofeven date herewith, the disclosure of which is hereby incorporated byreference.

FIELD OF THE DISCLOSURE

This disclosure generally relates to information handling systems, andmore particularly relates to a system and method for providingpersistent authentication in an information handling system.

BACKGROUND

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option is an information handling system. An information handlingsystem generally processes, compiles, stores, and/or communicatesinformation or data for business, personal, or other purposes. Becausetechnology and information handling needs and requirements may varybetween different applications, information handling systems may alsovary regarding what information is handled, how the information ishandled, how much information is processed, stored, or communicated, andhow quickly and efficiently the information may be processed, stored, orcommunicated. The variations in information handling systems allow forinformation handling systems to be general or configured for a specificuser or specific use such as financial transaction processing,reservations, enterprise data storage, or global communications. Inaddition, information handling systems may include a variety of hardwareand software resources that may be configured to process, store, andcommunicate information and may include one or more computer systems,data storage systems, and networking systems.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration,elements illustrated in the Figures have not necessarily been drawn toscale. For example, the dimensions of some of the elements areexaggerated relative to other elements. Embodiments incorporatingteachings of the present disclosure are shown and described with respectto the drawings presented herein, in which:

FIG. 1 is a block diagram of an authentication framework according to anembodiment of the present disclosure;

FIG. 2 is a block diagram of a persistent authentication engine of aninformation handling system in the authentication framework of FIG. 1;

FIG. 3 is a graph of a confidence score generated by the persistentauthentication engine of FIG. 2;

FIG. 4 is a block diagram of a resource authentication agent of theinformation handling system in the authentication framework of FIG. 1,according to an embodiment of the present disclosure;

FIG. 5 is a graph of the confidence score generated by the persistentauthentication engine of FIG. 2, including current authentication stateinformation associated with the confidence score, according to anembodiment of the present disclosure;

FIG. 6 is a graph of the confidence score generated by the persistentauthentication engine of FIG. 2, including current authentication stateinformation associated with the confidence score, according to anotherembodiment of the present disclosure;

FIG. 7 is a block diagram of another embodiment of a resourceauthentication agent of the information handling system in theauthentication framework of FIG. 1;

FIG. 8 is a block diagram of another embodiment of a resourceauthentication agent of the information handling system in theauthentication framework of FIG. 1;

FIG. 9 is a flowchart illustrating a method of providing persistentauthentication on an information handling system according to anembodiment of the present disclosure; and

FIG. 10 is a block diagram illustrating a generalized informationhandling system according to an embodiment of the present disclosure.

The use of the same reference symbols in different drawings indicatessimilar or identical items.

DETAILED DESCRIPTION OF DRAWINGS

The following description in combination with the Figures is provided toassist in understanding the teachings disclosed herein. The followingdiscussion will focus on specific implementations and embodiments of theteachings. This focus is provided to assist in describing the teachings,and should not be interpreted as a limitation on the scope orapplicability of the teachings. However, other teachings can certainlybe used in this application. The teachings can also be used in otherapplications, and with several different types of architectures, such asdistributed computing architectures, client/server architectures, ormiddleware server architectures and associated resources.

The present disclosure describes an authentication framework for aninformation handling system. The authentication framework includesvarious authentication devices and context engines which provide inputsto a persistent authentication engine. The persistent authenticationengine receives the inputs and provides a confidence score thatcharacterizes the authentication status of a user of the informationhandling system. The confidence score can increase or decrease basedupon various authentication events, such as risk events, assuranceevents, context events, recognition events, and time-based events.

Risk events are actions or events on the information handling systemwhich tend to decrease the confidence that a current user of theinformation handling system is the same as the user who initiated asession on the information handling system. For example, a long idletime may be considered as a risk event. Assurance events are actions orevents which tend to increase the confidence that the current user isthe same as the user who initiated the session, and includes initiallogon and authentication activities. Context events are actions orevents on the information handling system that indicate that anoperating state of the information handling system has changed, such asthe opening or closing of a laptop computer. Recognition events areactions or events that lend credibility to the identity of theauthenticated user, such as keyboard typing pattern recognition, and thelike.

The various event information is provided to a confidence algorithmmodule within the persistent authentication engine to generate theconfidence score. The persistent authentication engine can include oneor more confidence thresholds that are provided to define authenticationstates based upon the confidence score. For example, when the confidencescore is below a particular threshold the information handling systemmay be defined as being in a Restricted state, when the confidence scoreis above a second threshold the information handling system may bedefined as being in a Transactional state, and when the confidence scoreis between the two thresholds the information handling system may bedefined as being in an Authenticated state. The user's ability to accessand interact with various resources of the information handling systemcan be determined by the confidence score or by the authenticationstate.

The persistent authentication engine provides one or more of theconfidence score, the authentication state, and confidence scoremeta-data associated with the various event information that went intogenerating the confidence score, to one or more resource authenticationagents. Each resource authentication agent uses the information providedby the persistent authentication engine to control the user's ability toaccess and interact with a secure resource. In a first embodiment of aresource authentication agent, the resource authentication agentreceives a request to access the secure resource, and provides aconfidence score request to the persistent authentication engine. Inresponse to receiving the confidence score request, the resourceauthentication agent compares the confidence score with a resourceconfidence threshold to determine if the current confidence score issufficient to access the secure resource. If so, the resourceauthentication agent unlocks the secure resource. If the confidencescore is insufficient to access the secure resource, the resourceauthentication agent provides a reauthentication request. Thereauthentication request can be handled by the persistent authenticationengine or by another module to prompt the user to provide furthercredential information, thereby increasing the confidence score, andpermitting the user to access the secure resource.

A second embodiment of a resource authentication agent is similar to thefirst embodiment, as described above, except that the resourceauthentication agent provides a request for the current authenticationstate of the information handling system from the persistentauthentication engine, and where access to the secure resource and thereauthentication request are provided based upon the authenticationstate.

A third embodiment of a resource authentication agent receives theconfidence score meta-data and provides access to the secure resourceand the reauthentication request based upon the confidence scoremetadata. In this embodiment, the resource authentication agent has muchmore flexibility to tune the access criteria for the secure resource asneeded or desired. For example, the confidence score metadata caninclude a time stamp for a most recent finger-print scan from the user,and if the time since the most recent finger-print scan exceeds aparticular time limit, the resource authentication agent can provide thereauthentication request to receive a fresh finger-print scan, even ifthe confidence score is sufficient to provide access to the secureresource.

The resource authentication agents can reside on the informationhandling system or can be remote from the information handling system.Likewise, the secure resources that are accessed via the resourceauthentication agents can reside on the information handling system orcan be remote from the information handling system.

FIG. 1 illustrates an authentication framework 100 including aninformation handling system 110 connected to a remote token storage 130,and to a remote resource authentication agent 140 that operates toprovide access to a remote secure resource 145 to the informationhandling system. Information handling system 110 includes a capturedevice 112, a user interface device 114, a context engine 116, arecognition engine 118, a token storage 120, a persistent authenticationengine 122, a resource authentication agent 124 and a secure resource126. Capture device 112 represents one or more devices that provideparticular input data to information handling system 110 that is adaptedto verify the identity of a user of the information handling system. Inparticular, by interacting with capture device 112, a particularphysical feature of the user is captured and compared with a copy ofthat physical feature that is know and verified to be associated withthe user. An example of capture device 112 can include a special purposedevice such as a finger-print scanner or an iris scanner, a generalpurpose device adapted to identify a particular physical feature, suchas a touch screen adapted to identify a finger-print or a camera deviceadapted to scan a user's iris, or another device, as needed or desired.

User interface device 114 represents one or more general purpose devicethat can be utilized to perform various user identity validationfunctions, such as a keyboard/mouse upon which a user can provide log-incredentials like a username/password pair, an authenticated securitytoken, such as may be employed on a plug-in dongle, a wireless devicelike a Near Field Communication device or Bluetooth device, anotherdevice suitable for identifying the user, or the like. Context engine116 represents a wide variety of inputs which provide an identificationof the context within which information handling system 110 is beingutilized. For example, context engine 116 can represent one or moredevices or software functions operable to identify a power managementstate of information handling system 110, such as a lid-open/lid-closedstate for a laptop computer, a motion detector that detects thatinformation handling system 110 has been picked up, operating systemsoftware that detects a task or application switch by the user, anothercontext action or transaction, or the like. Recognition engine 118represents a wide variety of inputs which provide an identification ofthe user of information handling system 110, such as facial recognition,key-stroke pattern recognition, other recognition modes, or the like. Inparticular, methods and devices that are suitable for use as one or moreof capture device 112, user interface device 114, context engine 116,and recognition engine 118 are understood by the skilled artisan andparticulars of such devices and engines will not be further disclosedherein.

Token storage 120 and remote token storage 130 operate to securely storeone or more authenticated security tokens. The authenticated securitytokens can be associated with multiple users, or with multiple devices112 and 114, and engines 116 and 118. Secure resource 126 and remotesecure resource 145 represent one or more hardware, software, program,or application resources that are restricted in their access, based upona user's credentials. For example, secure resource 126 and remote secureresource 145 can include a storage volume or memory device, a program, aweb application, another hardware or software item that is sought to besecured, or the like.

Capture device 112, user interface device 114, context engine 116, andrecognition engine 118 are connected to persistent authentication engine122 to provide information related to various authentication events,such as risk events, assurance events, context events, recognitionevents, and time-based events. In determining the identity of a userassociated with the various authentication events, the user interactswith one or more of capture device 112, user interface device 114,context engine 116, and recognition engine 118 to provide a generatedsecurity token that is associated with the purported user. In aparticular embodiment, the device 112 or 114, or engine 116 or 118 thatprovided the generated security token requests an authenticated securitytoken that is associated with the purported user from one or more oftoken storage 120 and remote token storage 130, and, upon receipt of theauthenticated security token, the requesting device or engine comparesthe authenticated security token to the generated security token tovalidate that the purported user is, in fact, a user that is authorizedto utilize information handling system 110. If the purported user isvalidated to be the authorized user by the particular device 112 or 114,or engine 116 or 118, the device or engine provides an indication thatthe user is authorized to utilize information handling system 110. In aparticular embodiment, the particular device 112 or 114, or engine 116or 118 also provides an indication when the purported user is notvalidated to be the authorized user.

In another embodiment, the device 112 or 114, or engine 116 or 118 thatprovided the generated security token provides the generated securitytoken to persistent authentication engine 122, and the persistentauthentication engine requests the authenticated security token that isassociated with the purported user from one or more of token storage 120and remote token storage 130. Then, upon receipt of the authenticatedsecurity token, persistent authentication engine 122 compares theauthenticated security token to the generated security token to validatethat the purported user is, in fact, a user that is authorized toutilize information handling system 110. If the purported user isvalidated to be the authorized user, the persistent authenticationengine 122 generates an internal indication that the user is authorizedto utilize information handling system 110. In a particular embodiment,persistent authentication engine 122 also provides an internalindication when the purported user is not validated to be the authorizeduser.

Each act of validating the purported user as being authorized or not,constitutes a particular event, which, along with other events asdescribed further below, is evaluated by persistent authenticationengine 122 to generate confidence information, including a confidencescore, an authentication state, and confidence score meta-dataassociated with the event information. Persistent authentication engine122 operates to provide the confidence information to resourceauthentication agent 124 and to remote resource authentication agent140.

Resource authentication agent 124 receives a request from the user ofinformation handling system 110 to access secure resource 126. Inresponse, resource authentication agent 124 requests the confidenceinformation from persistent authentication engine 122, and determines,based upon one or more of the confidence score, the authenticationstate, or the confidence score meta-data, whether or not the user hassufficient authorization to access secure resource 126. If so, resourceauthentication agent 124 permits the user to access secure resource 126.If the user does not have sufficient authorization to access secureresource 126, then resource authentication agent 124 bars access to thesecure resource to the user and requests persistent authenticationengine 124 to solicit the user to provide additional information wherebythe persistent authentication engine can increase one or more of theconfidence score or the authentication state, or otherwise modify theconfidence score meta-data such that the user is permitted to accesssecure resource 126. Remote resource authentication agent 140 operatessimilarly to resource authentication agent 124 to grant or deny accessto remote secure resource 145. Here, persistent authentication engine124 operates to provide the confidence information to remote resourceauthentication agent 140 via a network interface of information handlingsystem 110. In this case, persistent authentication engine 122 can besecurely linked to remote resource authentication agent 140, such asthrough a dedicated network connection, a Virtual Private Network (VPN),or another secure link. Moreover, that the communication between thepersistent authentication engine and the remote resource authenticationagent can be encrypted to provide additional security, such as via apublic-key-infrastructure, a private key, or other encryption mechanism,as needed or desired.

Note that resource authentication agent 124 will be understood tocontrol access to one or more additional secure resources, and that suchadditional secure resources can be local to information handling system110, or remote there from. Likewise, remote resource authenticationagent 140 will be understood to control access to one or more additionalsecure resources, and that such additional secure resources can be localto information handling system 110, or remote there from.

FIG. 2 illustrates an embodiment of a persistent authentication engine200, similar to persistent authentication engine 122, including an eventengine 210, a confidence algorithm module 220, a confidence thresholdtable 230, and a time base 240. Persistent authentication engine 200receives an authentication request from a resource authentication agent,a capture input from a capture device, a user interface input from auser interface device, a context input from a context engine, arecognition input, and a token input, and provides confidence scoremeta-data, a confidence score, and an authentication state. Theauthentication request includes requests for persistent authenticationengine 200 to provide one or more of the confidence score meta-data, theconfidence score, and the authentication state to the resourceauthentication agent, and requests for the persistent authenticationagent to solicit a user to provide additional information whereby thepersistent authentication engine can increase one or more of theconfidence score or the authentication state, or otherwise modify theconfidence score meta-data such that the user is permitted to access asecure resource.

In a particular embodiment, the capture input, the user interface input,the context input, and the recognition input represent indications thata user is authorized to utilize the information handling system, or thatthe particular device or engine determined that the purported user isnot validated to be the authorized user. In another embodiment, thecapture input, the user interface input, the context input, and therecognition input represents a generated security token, and eventengine 210 requests an authenticated security token that is associatedwith the purported user from a token storage. Event engine 210 receivesthe authenticated security token on the token input and compares theauthenticated security token to the generated security token to validatethat the purported user is, in fact, a user that is authorized toutilize the information handling system. If the purported user isvalidated to be the authorized user, event engine 200 generates aninternal indication that the user is authorized to utilize theinformation handling system. In a particular embodiment, persistentauthentication engine 200 also provides an internal indication when thepurported user is not validated to be the authorized user.

Event engine 210 determines whether information provided by captureinput, user interface input, context input, and recognition inputconstitute one of several different types of events. In particular,event engine 210 includes a risk event module 212 to determine if aninput constitutes a risk event, an assurance event module 214 todetermine if an input constitutes a assurance event, a context eventmodule 216 to determine if an input constitutes a context event, and arecognition event module 218 to determine if an input constitutes arecognition event. As noted above, risk events are actions or events onthe information handling system which tend to decrease the confidencethat a current user of the information handling system is the same asthe user who initiated a session on the information handling system. Anexample of a risk event includes a long idle time may, a failedauthentication attempt, a change to the WiFi SSID for the informationhandling system, a change in a MAC address for the information handlingsystem, a change to the facial recognition pattern detected by theinformation handling system, another similar occurrence, or acombination thereof. Assurance events are actions or events which tendto increase the confidence that the current user is the same as the userwho initiated the session, and includes initial logon and authenticationactivities, swipe pattern unlock activities, and the like. Contextevents are actions or events on the information handling system thatindicate that an operating state of the information handling system haschanged, such as the opening or closing of a laptop computer.Recognition events are actions or events which lend credibility to theidentity of the authenticated user, such as various pattern recognitionactivities. Note that some types of actions or events can be consideredas more than one of a risk event, an assurance event, a context event,and a recognition event, as needed or desired.

Information related to the determinations made by modules 212-218 isprovided as confidence score meta-data to one or more resourceauthentication agent that can use the confidence score meta-data tocraft a customizable authentication scheme, as described further, below.In particular, the confidence score meta-data can include suchinformation as log-in attempts and whether or not the log-in attemptswere successful, a time stamp from time base 240 as to when a log-inattempt was performed or how many log-in attempts were tried in aparticular amount of time. The confidence score meta-data can alsoinclude a time stamp indicating the freshness of a particular assuranceevent. Further, the confidence score meta-data can include informationas to the source of a context event, such as whether a context switchwas instituted by a user, software, or another device of the informationhandling system. Moreover, the confidence score meta-data can includeinformation as to a degree of confidence included in a particularrecognition event, such as a percent match on a facial recognitionevent.

The information related to the determinations made by event modules212-218 is also provided to confidence algorithm module 220. Confidencealgorithm module 220 operates to determine a confidence score thatmeasures the level of confidence that a current user of the informationhandling system is an authenticated user and is the same as the user whoinitiated the session on the information handling system. In aparticular embodiment, the confidence score is provided in terms of apercentage, from 0% to 100% confidence. In another embodiment, theconfidence score is provided on a numbered scale, such as from 0-10,where zero (0) is a low confidence level and ten (10) is a highconfidence level. Hereinafter, the confidence level shall be describedin terms of a percentage confidence level. Confidence algorithm module220 can represent an equation with inputs from event modules 212-218 andtime base 240 that calculates the confidence score, can represent a setof rules that correlate the event modules' and time base inputs to theconfidence score, or can represent a combination of an equation and aset of rules.

FIG. 3 is a graph 300 of an exemplary confidence score generated bypersistent authentication engine 200 which illustrates the operation ofconfidence algorithm module 220. At time “0,” the information handlingsystem is unaware of any user interaction. This state can represent apower off state, a suspended state, a sleep state, a hibernation state,or another such state, as needed or desired. At time 302, theinformation handling system is set into a state that is prepared toreceive a user input, such as by powering on the information handlingsystem, resuming from the suspended state, waking from the sleep orhibernation state, or otherwise preparing the information handlingsystem to receive a user input, as needed or desired. However, beforereceiving any user inputs, the confidence score is initially 0%. Thatis, no user has been identified on the information handling system.

At this point, the information handling system can prompt a user toprovide one or more authentication credentials, such as ausername/password log-on, an iris scan log-on, a finger-print scanlog-on, another authentication credential, or a combination thereof, asneeded or desired. For example, at time 304, the user can successfullyprovide a username/password log-on credential, and confidence algorithmmodule 220 can ascribe a 40% confidence score to a successfulusername/password log-on attempt, and so the confidence score isincreased to 40%. Next, at time 306, the user can successfully providean iris scan credential, and confidence algorithm module 220 can ascribea 30% confidence score to a successful iris scan attempt, and so theconfidence score is increased to 70%. Finally, at time 308, the user cansuccessfully provide a finger-print scan log-on credential, andconfidence algorithm module 220 can ascribe a 30% confidence score to asuccessful finger-print scan attempt, and so the confidence score isincreased to 100%.

In a particular embodiment, confidence engine 220 can ascribe a variableconfidence score to one or more type of assurance event. For example, insome cases, a credential can be provided locally at the informationhandling system, from a non-secure remote resource, such as anun-trusted web server, and also from a secure remote resource, such as atrusted web server. Here, confidence engine 220 can ascribe a base levelconfidence score to a credential that is provided locally. For example,a username/password log-on that is provided locally can be ascribed a40% confidence score. On the other hand, confidence engine 220 canascribe a discounted confidence score to a credential that is providedfrom a non-secure remote source. For example, a username/password log-onthat is provided from an un-trusted web server can be ascribed a 25%confidence score. Finally, confidence engine 220 can ascribe a premiumconfidence score to a credential that is provided from a secure remotesource. For example, a username/password log-on that is provided from atrusted web server can be ascribed a 50% confidence score. Note thatsuch grading of assurance events can be provided in confidence engine220 on a case-by-case basis, where each type of assurance event andsource combination is given a set discount or premium, as needed ordesired. The grading of assurance events can also be provided as ablanket rule. Here, a fixed discount or premium can be applied to theassurance events. The fixed discount or premium can be defined as a setscore adder, or can be defined as a percentage of the base confidencelevel.

At time 308, after having successfully provided credentials to increasethe confidence score to 100%, the user provides no additional input tothe information handling system for a time, causing confidence algorithmmodule 220 to reduce the confidence score. In a particular embodiment,the confidence score can be decreased linearly with time, exponentiallywith time, or according to another relationship with non-activity. Inanother embodiment, confidence algorithm module 220 can permit a dwelltime, such as one minute, thirty seconds, or another dwell time, beforethe confidence score begins to decrease.

At time 310, the user begins using the information handling system andthe confidence score begins a region of passive authentication. Here,various recognition events are provided to confidence algorithm module220 that lend increased validity to the user. For example, in the timespan between time 308 and 310, the user may have stepped away from theinformation handling system, while after time 310, the user may havereturned. Here, when the user returned, facial recognition software mayprovide increased confidence that the user is the authenticated user, orusage patterns may such confidence, and so confidence algorithm module220 increases the confidence score. Because the user provides noaffirmative log-in credentials during this time, but the confidencescore is increasing, this region is called passive authentication. In aparticular embodiment, the confidence score can only increase to acertain level due to passive authentication. Here, at time 312, theconfidence score has been increased to 90% due to various passiveauthentication activities by the user, but confidence algorithm module220 does not increase the confidence score beyond 90%.

At time 314, the user performs a reverse authentication event. Here,confidence algorithm module 220 provides a large decrease in theconfidence score in response to the event. In a particular embodiment,the decrease in the confidence score is provided as a particularconfidence level, such as 10%, as a percentage rule, such as—(reduce thecurrent confidence score by 90%), as a score rule, such as—(reduce thecurrent confidence score by 75), or by another reduction method asneeded or desired. A particular example of a reverse authenticationevent is the placing of the information handling system into a sharedmode, as described further, below. Another example of a reverseauthentication event includes detection of a particular gesture or voicecommand, a keyboard sequence, such as CTL-ALT-DEL, loss of network,WiFi, or Bluetooth connection, another event, or a combination thereof.In a particular embodiment, confidence algorithm module 220 can providefor different levels of reverse authentication events, such that a firstevent triggers a small decrease in the confidence score, a second eventtriggers a larger decrease in the confidence score, and so forth.

At times 316, 318, and 320, the user provides authentication credentialssimilarly to times 304, 306, and 308, as described above, and confidencealgorithm module 220 increases the confidence score back to 100%. Aftertime 320, the user proceeds to utilize the information handling systemand so the confidence level remains at 100%. At time 322, the user quitsusing the information handling system, and confidence algorithm module220 begins to reduce to confidence score, as described above. At time324, the user shuts down the information handling system, such that theinformation handling system is unaware of any user input, and theconfidence score drops to 0%.

FIG. 4 illustrates a first embodiment of a resource authentication agent410 that controls the access to a secure resource 420. Resourceauthentication agent 410 includes an access request processor 412, aresource confidence threshold table 414, a comparator 416, and aninverter 418. Resource authentication agent 410 receives a request toaccess secure resource 420 from a user. The request can represent agradation of requests to access secure resource 420. For example, wheresecure resource 420 is a file, a particular request can be to receiveread access to the secure resource, to receive read/write access to thesecure resource, to receive read/write and create/delete access to thesecure resource, or to receive other types of access as needed ordesired. Access request processor 412 operates to provide a confidencescore request to a persistent authentication engine, and to provide anaccess level indication to resource confidence threshold table 414.

Resource confidence threshold table 414 includes one or more confidencelevel threshold. Each confidence level threshold defines a confidencelevel score needed in order to access a particular function of featureof secure resource 420. In response to the request for the currentconfidence score, the persistent authentication engine provides thecurrent confidence score to resource authentication agent 410, and theresource authentication agent compares the confidence score withselected resource confidence threshold from resource confidencethreshold table 414 to determine if the current confidence score issufficient to access the secure resource. The resource confidence levelis selected by access request processor 412, based upon the level ofaccess to secure resource 420 that is requested. For this reason, theoutput of resource confidence threshold table 414 is illustrated as amultiple output.

If the confidence score is greater than the selected resource confidencethreshold, resource authentication agent 410 unlocks secure resource 420to a level specified by the selected resource confidence threshold. Ifthe confidence score is less than the selected resource confidencethreshold, resource authentication agent 410 provides a reauthenticationrequest by inverting the output of comparator 416 with inverter 418. Thereauthentication request can be handled by the persistent authenticationengine or by another module to prompt the user to provide furthercredential information, thereby increasing the confidence score, andpermitting the user to access the secure resource. In a particularembodiment, when resource authentication agent 410 unlocks secureresource 420, the resource authentication agent provides an indicationto the persistent authentication engine that the secure resource hasbeen unlocked for the user. Note that the illustration of resourceauthentication agent 410, and particularly comparator 416 and inverter418, are here illustrative of functional operations as described above,and are not intended to depict a particular circuit implementation,although such is not precluded herein.

Returning to FIG. 2, persistent authentication module 200 furtheroperates to provide the confidence score to confidence threshold table230. Confidence threshold table 230 includes one or more confidencelevel threshold. Each confidence level threshold defines anauthentication state for the information handling system. Here, theconfidence level thresholds as included in confidence threshold table230 is similar to the confidence level threshold as included in resourceconfidence threshold table 414, as described above, except that theconfidence level thresholds of confidence threshold table 230 areapplied globally to the information handling system, while theconfidence level threshold of the resource confidence threshold tableare specific to secure resource 420.

Persistent authentication engine 200 provides the current confidencescore to confidence threshold table 230, and the confidence thresholdtable compares the confidence score with the confidence level thresholdsto determine the authentication level for the information handlingsystem. For example, when the confidence score is below a particularthreshold, the information handling system may be defined as being in aRestricted state, when the confidence score is above a second threshold,the information handling system may be defined as being in aTransactional state, and when the confidence score is between the twothresholds, the information handling system may be defined as being inan Authenticated state. The user's ability to access and interact withvarious resources of the information handling system can be determinedby the confidence score or by the authentication state.

In a particular embodiment, the values stored in confidence thresholdtable 230 are pre-determined, such as by a hardware, firmware, or BIOSsetting of the information handling system. In another embodiment, thevalues stored in confidence threshold table 230 are selectable, such asby a user with administrative privileges to the information handlingsystem, or through a BIOS setting. In yet another embodiment, confidencethreshold table 230 represents more than one set of confidence levelthresholds, each set being associated with a different resourceauthentication agent, and different authentication states can beprovided to each associated resource authentication agent based upon itsassociated set of confidence level thresholds. Here, the different setsof confidence level thresholds can be pre-determined, or can be providedby the associated resource authentication agent.

FIG. 5 is a depiction of a graph 500 similar to graph 300, withexemplary authentication states overlaid. In particular, graph 500illustrates a Locked state where the information handling system isunaware of any user interaction, a Shared state between 0% and 15%, aRestricted state between 15% and 40%, an Authenticated state between 40%and 70%, and a Transactional state between 70% and 100%. Here, theinformation handling system starts in the Locked state at time 0 andenters the Shared state at time 302. The authentication events marked bytimes 304, 306, and 308 successively transition the information handlingsystem to the Restricted state, the Authenticated state, and theTransactional state.

After time 308, when confidence algorithm module 220 reduces theconfidence score, the authentication state is reduced to theAuthenticated state when the confidence score is reduced to 70% at time402, and to the Restricted state when the confidence score is reduced to40% at time 404. During the passive authentication, when confidencealgorithm module 220 increases the confidence score, the authenticationstate is increased back to the Authenticated state when the confidencescore is increased to 40%, and to the Transactional state when theconfidence score is increased to 70%.

The information handling system remains in the Transactional state untiltime 314, when the reverse authentication event drops the confidencescore to 10%, at which time the information handling system enters theShared state. At times 316, 318, and 320, when the re-authenticationevents occur, the information handling system successively transitionsto the Restricted state, the Authenticated state, and the Transactionalstate. The information handling system remains in the Transactionalstate until the confidence score hits 70%, at time 410, and theinformation handling system is returned to the Locked state at time 324when the information handling system is shut down.

As noted above, in the Locked state, the information handling system isunaware of any user interaction. In the Shared state, access is onlyprovided to resources which do not require any authenticationcredentials. For example, the Shared state can permit the use ofcellular telephone functions of a mobile device, games, and the like. Inthe Restricted state, access is provided to low-confidence levelresources, such as web browsing, file read access, or the like, butaccess to secure resources may be limited, such as downloadrestrictions, or no-write and no-create/delete access. In theAuthenticated state, access is provided to medium-confidence levelresources, such as web downloading of files, but not of executables, orfile read/write access. Finally, in the Transactional state, full accessis provided to all high-confidence level resources, such as alldownloading, create/delete file access, system configuration, and thelike.

FIG. 6 is a depiction of a graph 600 similar to graph 500, withexemplary authentication states overlaid. In particular, graph 600illustrates an embodiment where passive authentication is only permittedto raise the confidence score to the limit of the present authenticationstate. Here, confidence algorithm module 220 begins to decrease theconfidence score at time 602, and the confidence score decreases throughthe Transactional state and the Authenticated state, and enters theRestricted state at time 604. At time 606, the user begins to interactwith the information handling system, and the passive authenticationbegins to cause confidence algorithm module 220 to increase theconfidence score. Here, the fine line illustrates what the confidencescore would be if there were no limit on increasing the authenticationstate through passive authentication. However, because of the limitationthat the authentication state is not permitted to increase due to thepassive authentication, the confidence score remains at 40% at time 608,and the information handling system remains in the Restricted state,rather than increasing through the Authenticated state and theTransactional state. In a particular embodiment, the limitation uponchanging state due to passive authentication can be applied on astate-by-state basis. For example, passive authentication may bepermitted to raise the confidence score from the Shared state to theRestricted state, or passive authentication may be permitted to raisethe confidence score from the Authenticated state to the Transactionalstate, and only the transition from the Restricted state to theAuthenticated state may be denied. Note that the foregoing exampleassumes that transitions can only be made between adjacentauthentication states, but this is not necessarily so, and the skilledartisan will recognize that other particular cases can be envisionedwhere transitions between non-adjacent states are allowed.

FIG. 7 illustrates a second embodiment of a resource authenticationagent 710 that controls the access to a secure resource 720. Resourceauthentication agent 710 includes an access request processor 712, aresource state threshold table 714, a comparator 716, and an inverter718. Resource authentication agent 710 receives a request to accesssecure resource 720 from a user. The request can represent a gradationof requests to access secure resource 720. Access request processor 712operates to provide an authentication state request to a persistentauthentication engine, and to provide an access level indication toresource state threshold table 714.

Resource state threshold table 714 includes a state map that maps thevarious authentication states with the permitted level of access tosecure resource 720. In response to the request for the currentauthentication state, the persistent authentication engine provides theauthentication state to resource authentication agent 710, and theresource authentication agent compares the authentication state withselected entry of the state map of resource state threshold table 714 todetermine if the current authentication state is sufficient to accesssecure resource 720. If the authentication state is greater than orequal to the selected resource state threshold, resource authenticationagent 710 unlocks secure resource 720 to a level specified by theselected resource score threshold. If the authentication state is lessthan the selected resource state threshold, resource authenticationagent 710 provides a reauthentication request by inverting the output ofcomparator 716 with inverter 718. The reauthentication request can behandled by the persistent authentication engine or by another module toprompt the user to provide further credential information, therebyincreasing the confidence score, and permitting the user to access thesecure resource. In a particular embodiment, when resourceauthentication agent 710 unlocks secure resource 720, the resourceauthentication agent provides an indication to the persistentauthentication engine that the secure resource has been unlocked for theuser. Note that the illustration of resource authentication agent 710,and particularly comparator 716 and inverter 718, are here illustrativeof functional operations as described above, and are not intended todepict a particular circuit implementation, although such is notprecluded herein.

FIG. 8 illustrates a third embodiment of a resource authentication agent810 that controls the access to a secure resource 830. Resourceauthentication agent 810 includes an access request processor 812, aresource confidence threshold table 814, a confidence algorithm module816, a comparator 818, an inverter 820, and a time base 822. Resourceauthentication agent 810 receives a request to access secure resource830 from a user. The request can represent a gradation of requests toaccess secure resource 830. Access request processor 812 operates toprovide a confidence score meta-data request to a persistentauthentication engine, and to provide an access level indication toresource confidence threshold table 814.

Resource confidence threshold table 814 includes one or more confidencelevel threshold that defines a confidence level score needed in order toaccess a particular function of feature of secure resource 830. Inresponse to the request for the current confidence score meta-data, thepersistent authentication engine provides the current confidence scoremeta-data to confidence algorithm module 816. Confidence algorithmmodule 816 is similar to confidence algorithm module 220, and uses theconfidence score meta-data to determine a confidence score. Here theconfidence score determined by confidence algorithm module 816 can becalculated in the same way as the confidence score from the persistentauthentication engine, that is, based upon a same equation or set ofrules, or can be calculated differently from the confidence score fromthe persistent authentication engine.

Confidence algorithm module 816 provides the confidence score tocomparator 818 and the comparator compares the confidence score with aselected resource confidence threshold from resource confidencethreshold table 814 to determine if the current confidence score issufficient to access the secure resource. The resource confidence levelis selected by access request processor 812, based upon the level ofaccess to secure resource 830 that is requested. For this reason, theoutput of resource confidence threshold table 814 is illustrated as amultiple output.

If the confidence score is greater than the selected resource confidencethreshold, resource authentication agent 810 unlocks secure resource 830to a level specified by the selected resource confidence threshold. Ifthe confidence score is less than the selected resource confidencethreshold, resource authentication agent 810 provides a reauthenticationrequest by inverting the output of comparator 818 with inverter 820. Thereauthentication request can be handled by the persistent authenticationengine or by another module to prompt the user to provide furthercredential information, thereby increasing the confidence score, andpermitting the user to access the secure resource. In a particularembodiment, when resource authentication agent 810 unlocks secureresource 830, the resource authentication agent provides an indicationto the persistent authentication engine that the secure resource hasbeen unlocked for the user.

In a particular embodiment, confidence algorithm module 816 operates toprovide the confidence score meta-data to time base 822 to determine ifan assurance event has gone stale. That is, time base 822 applies a timelimit to one or more assurance events. For example, time base 822 canprovide a time limit for receiving finger-print scan authenticationcredentials, such that, if no finger-print scan authenticationcredential has been received within the previous hour, then time base822 issues a reauthentication request. Here, notwithstanding aconfidence score that, based upon the confidence score meta-data alone,would indicate that secure resource 830 should be unlocked, resourceauthentication agent 810 will maintain the lock on secure resource 820until such time as a fresh finger-print scan authentication credentialis received by the persistent authentication engine, and the confidencescore meta-data is updated to reflect that fact.

Because resource authentication agent 810 includes its own confidencealgorithm module 816, the resource authentication agent has a highdegree of flexibility to manage and control the conditions under whichsecure resource 830 is unlocked. Note that the illustration of resourceauthentication agent 810, and particularly comparator 818, inverter 820,and time base 822, are here illustrative of functional operations asdescribed above, and are not intended to depict a particular circuitimplementation, although such is not precluded herein.

FIG. 9 illustrates a method of providing persistent authentication on aninformation handling system, starting at step 902 where a user requestsaccess to a secure resource of the information handling system from aresource authentication agent. In step 904, the resource authenticationagent responds to the access request from the user by requestingconfidence level information from a persistent authentication engine.For example, the resource authentication agent can request a confidencescore, an authentication state, or confidence score meta-data from thepersistent authentication engine. The persistent authentication engineprovides the requested authentication information to the resourceauthentication agent in step 906.

The resource authentication agent determines if the user isauthenticated to a sufficient level to grant access to the secureresource in decision block 908. For example, the resource authenticationagent can compare the confidence score or the authentication state withscore or state thresholds, or can derive a confidence score from theconfidence score meta-data to compare with the score threshold, in orderto determine if the user is authenticated to the sufficient level. Ifso, the “YES” branch of decision block 908 is taken, the resourceauthentication agent grants the user access to the secure resource inblock 910 and provides an indication to the persistent authenticationengine that the access to the secure resource was granted to the user instep 912, and the method ends.

If the user is not authenticated to the sufficient level to grant accessto the secure resource, the “NO” branch of decision block 908 is takenand the resource authentication agent provides a reauthenticationrequest to the persistent authentication engine in step 914. Thepersistent authentication engine prompts the user to provide anadditional authentication credential in step 916. For example, the usercan be prompted to provide a username/password log-on, a finger-print oriris scan, or another authentication credential. The user provides theadditional authentication credential to the persistent authenticationengine in step 918. The persistent authentication engine provides theupdated confidence information based upon the additional authenticationcredential to the resource authentication agent in step 920. Theresource authentication agent grants the user access to the secureresource in block 922, provides an indication to the persistentauthentication engine that the access to the secure resource was grantedto the user in step 924, and the method ends.

FIG. 10 illustrates a generalized embodiment of information handlingsystem 1000. For purpose of this disclosure information handling system1000 can include any instrumentality or aggregate of instrumentalitiesoperable to compute, classify, process, transmit, receive, retrieve,originate, switch, store, display, manifest, detect, record, reproduce,handle, or utilize any form of information, intelligence, or data forbusiness, scientific, control, entertainment, or other purposes. Forexample, information handling system 100 can be a personal computer, alaptop computer, a smart phone, a tablet device or other consumerelectronic device, a network server, a network storage device, a switchrouter or other network communication device, or any other suitabledevice and may vary in size, shape, performance, functionality, andprice. Further, information handling system 100 can include processingresources for executing machine-executable code, such as a centralprocessing unit (CPU), a programmable logic array (PLA), an embeddeddevice such as a System-on-a-Chip (SoC), or other control logichardware. Information handling system 1000 can also include one or morecomputer-readable medium for storing machine-executable code, such assoftware or data. Additional components of information handling system1000 can include one or more storage devices that can storemachine-executable code, one or more communications ports forcommunicating with external devices, and various input and output (I/O)devices, such as a keyboard, a mouse, and a video display. Informationhandling system 1000 can also include one or more buses operable totransmit information between the various hardware components.

Information handling system 1000 can include devices or modules thatembody one or more of the devices or modules described above, andoperates to perform one or more of the methods described above.Information handling system 1000 includes processors 1002 and 1004, achipset 1010, a memory 1020, a graphics interface 1030, include a basicinput and output system/extensible firmware interface (BIOS/EFI) module1040, a disk controller 1050, a disk emulator 1060, an input/output(I/O) interface 1070, and a network interface 1080. Processor 1002 isconnected to chipset 1010 via processor interface 1006, and processor1004 is connected to the chipset via processor interface 1008. Memory1020 is connected to chipset 1010 via a memory bus 1022. Graphicsinterface 1030 is connected to chipset 1010 via a graphics interface1032, and provides a video display output 1036 to a video display 1034.In a particular embodiment, information handling system 1000 includesseparate memories that are dedicated to each of processors 1002 and 1004via separate memory interfaces. An example of memory 1020 includesrandom access memory (RAM) such as static RAM (SRAM), dynamic RAM(DRAM), non-volatile RAM (NV-RAM), or the like, read only memory (ROM),another type of memory, or a combination thereof.

BIOS/EFI module 1040, disk controller 1050, and I/O interface 1070 areconnected to chipset 1010 via an I/O channel 1012. An example of I/Ochannel 1012 includes a Peripheral Component Interconnect (PCI)interface, a PCI-Extended (PCI-X) interface, a high-speed PCI-Express(PCIe) interface, another industry standard or proprietary communicationinterface, or a combination thereof. Chipset 1010 can also include oneor more other I/O interfaces, including an Industry StandardArchitecture (ISA) interface, a Small Computer Serial Interface (SCSI)interface, an Inter-Integrated Circuit (I2C) interface, a System PacketInterface (SPI), a Universal Serial Bus (USB), another interface, or acombination thereof. BIOS/EFI module 1040 includes BIOS/EFI codeoperable to detect resources within information handling system 1000, toprovide drivers for the resources, initialize the resources, and accessthe resources. BIOS/EFI module 1040 includes code that operates todetect resources within information handling system 1000, to providedrivers for the resources, to initialize the resources, and to accessthe resources.

Disk controller 1050 includes a disk interface 1052 that connects thedisc controller to a hard disk drive (HDD) 1054, to an optical diskdrive (ODD) 1056, and to disk emulator 1060. An example of diskinterface 1052 includes an Integrated Drive Electronics (IDE) interface,an Advanced Technology Attachment (ATA) such as a parallel ATA (PATA)interface or a serial ATA (SATA) interface, a SCSI interface, a USBinterface, a proprietary interface, or a combination thereof. Diskemulator 1060 permits a solid-state drive 1064 to be connected toinformation handling system 1000 via an external interface 1062. Anexample of external interface 1062 includes a USB interface, an IEEE1394 (Firewire) interface, a proprietary interface, or a combinationthereof. Alternatively, solid-state drive 1064 can be disposed withininformation handling system 1000.

I/O interface 1070 includes a peripheral interface 1072 that connectsthe I/O interface to an add-on resource 1074 and to network interface1080. Peripheral interface 1072 can be the same type of interface as I/Ochannel 1012, or can be a different type of interface. As such, I/Ointerface 1070 extends the capacity of I/O channel 1012 when peripheralinterface 1072 and the I/O channel are of the same type, and the I/Ointerface translates information from a format suitable to the I/Ochannel to a format suitable to the peripheral channel 1072 when theyare of a different type. Add-on resource 1074 can include a data storagesystem, an additional graphics interface, a network interface card(NIC), a sound/video processing card, another add-on resource, or acombination thereof. Add-on resource 1074 can be on a main circuitboard, on separate circuit board or add-in card disposed withininformation handling system 1000, a device that is external to theinformation handling system, or a combination thereof.

Network interface 1080 represents a NIC disposed within informationhandling system 1000, on a main circuit board of the informationhandling system, integrated onto another component such as chipset 1010,in another suitable location, or a combination thereof. Networkinterface device 1080 includes network channels 1082 and 1084 thatprovide interfaces to devices that are external to information handlingsystem 1000. In a particular embodiment, network channels 1082 and 1084are of a different type than peripheral channel 1072 and networkinterface 1080 translates information from a format suitable to theperipheral channel to a format suitable to external devices. An exampleof network channels 1082 and 1084 includes InfiniBand channels, FibreChannel channels, Gigabit Ethernet channels, proprietary channelarchitectures, or a combination thereof. Network channels 1082 and 1084can be connected to external network resources (not illustrated). Thenetwork resource can include another information handling system, a datastorage system, another network, a grid management system, anothersuitable resource, or a combination thereof.

The skilled artisan will recognize that, where a particular device type,standard, or operation is specified, that suitable alternatives asneeded or desired can be incorporated along with the teachings herein.For example, where the present disclosure describes networkcommunications such as Ethernet communications, other communicationstandards, hardware, or software can be utilized to providecommunications of sufficient bandwidth to perform the operations,teachings, and methods as disclosed herein.

Although only a few exemplary embodiments have been described in detailherein, those skilled in the art will readily appreciate that manymodifications are possible in the exemplary embodiments withoutmaterially departing from the novel teachings and advantages of theembodiments of the present disclosure. Accordingly, all suchmodifications are intended to be included within the scope of theembodiments of the present disclosure as defined in the followingclaims. In the claims, means-plus-function clauses are intended to coverthe structures described herein as performing the recited function andnot only structural equivalents, but also equivalent structures.

The above-disclosed subject matter is to be considered illustrative, andnot restrictive, and the appended claims are intended to cover any andall such modifications, enhancements, and other embodiments that fallwithin the scope of the present invention. Thus, to the maximum extentallowed by law, the scope of the present invention is to be determinedby the broadest permissible interpretation of the following claims andtheir equivalents, and shall not be restricted or limited by theforegoing detailed description.

What is claimed is:
 1. An information handling system, comprising: afirst secure resource; a first input device that receives a firstauthentication credential from a user and generates first authenticationinformation based upon the first authentication credential; anauthentication engine that receives the first authentication informationand provides first confidence information based upon the firstauthentication information; and a first authentication agent thatreceives the first confidence information and grants to the user a firstlevel access to the first secure resource based upon the firstconfidence information.
 2. The information handling system of claim 1,wherein the information handling system receives an authenticated tokenfor the user in response to receiving the first authenticationcredential at the first input device.
 3. The information handling systemof claim 2, wherein the first input device: generates a generated tokenfor the user based upon the first authentication information; determinesif the generated token matches the authenticated token; and generatesthe first authentication information when the generated token matchesthe authenticated token.
 4. The information handling system of claim 1,wherein: the first authentication information comprises a generatedtoken for the user; in providing the first confidence information, theauthentication engine: determines if the generated token matches theauthenticated token; and provides the first confidence information whenthe generated token matches the authenticated token.
 5. The informationhandling system of claim 1, wherein: the confidence informationcomprises a confidence score that is based upon first authenticationinformation; and the first authentication agent grants the user thefirst level access to the first secure resource when the confidencescore is above a confidence score threshold.
 6. The information handlingsystem of claim 5, wherein: the confidence information further comprisesa confidence level that is based upon confidence score; and the firstauthentication agent grants the user the first level access to the firstsecure resource when the confidence level is above a confidence levelthreshold.
 7. The information handling system of claim 6, wherein: theconfidence information further comprises confidence metadata that isbased upon a condition of the authentication information; and the firstauthentication agent grants the user the first level access to the firstsecure resource based upon the confidence metadata.
 8. The informationhandling system of claim 1, further comprising: a second input devicethat receives a second authentication credential from the user andgenerates second authentication information based upon the secondauthentication credential; wherein: the authentication engine receivesthe second authentication information and provides second confidenceinformation based upon the second authentication information; and thefirst authentication agent that receives the second confidenceinformation and grants the user a second level access to the firstsecure resource based upon the second confidence information.
 9. Theinformation handling system of claim 1, further comprising: a secondsecure resource; and a second authentication agent that receives thefirst confidence information and grants the user a second level accessto the second secure resource based upon the first confidenceinformation.
 10. A method, comprising: receiving, at a first inputdevice of an information handling system, a first authenticationcredential from a user; generating first authentication informationbased upon the first authentication credential; receiving, at anauthentication engine of the information handling system, the firstauthentication information; providing first confidence information basedupon the first authentication information; receiving, at a firstauthentication agent of the information handling system, the firstconfidence information; and granting to the user a first level access toa first secure resource of the information handling system based uponthe first confidence information.
 11. The method of claim 10, furthercomprising: receiving an authenticated token for the user in response toreceiving the first authentication credential at the first input device.12. The method of claim 11, further comprising: generating, by the firstinput device, a generated token for the user based upon the firstauthentication information; and determining if the generated tokenmatches the authenticated token; and wherein the first authenticationinformation is generated when the generated token matches theauthenticated token.
 13. The method of claim 10, wherein: the firstauthentication information comprises a generated token for the user; inproviding the first confidence information, the method further comprisesdetermining if the generated token matches the authenticated token; andthe first confidence information is provided when the generated tokenmatches the authenticated token.
 14. The method of claim 10, wherein:the confidence information comprises a confidence score that is basedupon first authentication information; and the user is granted the firstlevel access to the first secure resource when the confidence score isabove a confidence score threshold.
 15. The method of claim 14, wherein:the confidence information further comprises a confidence level that isbased upon confidence score; and the user is granted the first levelaccess to the first secure resource when the confidence level is above aconfidence level threshold.
 16. The method of claim 15, wherein: theconfidence information further comprises confidence metadata that isbased upon a condition of the authentication information; and the useris granted the first level access to the first secure resource basedupon the confidence metadata.
 17. The method of claim 10, furthercomprising: receiving, by a second input device of the informationhandling system, a second authentication credential from the user;generating second authentication information based upon the secondauthentication credential; receiving, at the authentication engine, thesecond authentication information; and providing second confidenceinformation based upon the second authentication information; receiving,at the first authentication agent, the second confidence information;and granting the user a second level access to the first secure resourcebased upon the second confidence information.
 18. The method of claim10, further comprising: receiving, at a second authentication agent ofthe information handling system, the first confidence information; andgranting the user a second level access to a second secure resource ofthe information handling system based upon the first confidenceinformation.
 19. A non-transitory computer-readable medium includingcode for performing a method, the method comprising: receiving, at afirst input device of an information handling system, a firstauthentication credential; generating first authentication informationbased upon the first authentication credential; receiving, at anauthentication engine of the information handling system, the firstauthentication information; providing first confidence information basedupon the first authentication information; receiving the firstconfidence information; and granting a first level access to a firstsecure resource of the information handling system based upon the firstconfidence information.
 20. The computer-readable medium of claim 19,wherein: the first authentication information comprises a generatedtoken for the user; in providing the first confidence information, themethod further comprises determining if the generated token matches theauthenticated token; and the first confidence information is providedwhen the generated token matches the authenticated token.